MCP 2026-07-28 规范更新
发布日期： 2026年7月28日
分类： MCP 官方规范文章（非 Anthropic 博客）
来源： https://blog.modelcontextprotocol.io/posts/2026-07-28/
Model Context Protocol（MCP）2026-07-28 规范现已发布。本次更新引入无状态协议核心、多轮往返请求（Multi Round-Trip Requests，MRTR）、基于请求头的路由、可缓存的列表结果、强化后的授权机制、正式的扩展框架，以及更新后的 Tier 1 SDK。
自去年 11 月的版本发布以来，MCP 持续快速发展。Tier 1 SDK 的月下载量已接近 5 亿次，TypeScript 和 Python SDK 的累计下载量均突破 10 亿。短短数月间，MCP 已进一步成为 Agent 工作流的数据与交互底座。
今天，我们正式发布 2026-07-28 版 MCP 规范及配套 SDK，开发者可立即据此构建客户端和服务器。
本次最重要的变化是无状态协议核心：MCP 正从双向、有状态的协议转向请求/响应式的无状态协议。它是开发者呼声最高的能力之一，旨在提升 MCP 服务器的可靠性和可扩展性。
本次还包括：
- 每个请求都自描述。需要预先了解能力的客户端可选用发现调用，因此请求可被普通轮询负载均衡器后的任一实例处理。
- 方法名和工具名通过
Mcp-Method、Mcp-NameHTTP 请求头传递，网关可直接据此进行路由和授权。 - 采样、elicitation 等服务端到客户端的请求改用 MRTR，不再依赖持续打开的双向流。
- 列表响应携带缓存提示和确定性顺序，客户端可缓存工具目录，并在重连时维持上游 prompt cache 的稳定性。
- 正式确立扩展框架；Tasks 与 MCP Apps、企业托管授权（Enterprise Managed Authorization，EMA）等一同成为扩展。
- 授权机制得到强化，包括 RFC 9207
iss校验，以及从动态客户端注册（DCR）转向客户端 ID 元数据文档（CIMD）。 - 设立正式弃用策略，最短过渡期为 12 个月，便于团队规划升级。
TypeScript、Python、Go 与 C# SDK 均已更新以支持该规范；其中包含破坏性变更的迁移说明，可立即开始使用。
具体变化
不再需要握手或协议会话
新规范正式移除了 initialize / initialized 交换和 Mcp-Session-Id 请求头，详见 SEP-2575 与 SEP-2567。每个请求独立发送，并通过 _meta 携带协议版本、客户端身份与客户端能力。
若客户端希望在开始操作前获知服务器能力，可调用新的 server/discover RPC，但这不是必需步骤。由于不再依赖共享存储，请求可以被普通轮询负载均衡器后的任一服务器实例处理。
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}移除协议层会话并不意味着应用必须无状态。若服务器需要跨调用保存状态，应由工具生成显式 handle，并让模型在后续调用中把它作为参数传回。相比隐藏在传输层的会话状态，这种方式更清晰：模型能看见 handle，并在不同工具调用间传递它。
多轮往返请求（MRTR）
MRTR 取代了过去要求保持流连接的服务端发起请求：elicitation/create、sampling/createMessage 和 roots/list。
工具有时需要在调用中向用户索取信息，例如确认操作或补充缺失参数。MRTR（SEP-2322）在无状态协议下支持这种场景：服务器返回 resultType: "input_required"，同时给出待回答的请求；客户端把答案放进 inputResponses，再重试原始调用。
基于请求头的路由
Streamable HTTP 请求现在必须携带 Mcp-Method 与 Mcp-Name，见 SEP-2243。网关、限流器或 WAF 无须解析 JSON 请求体，即可依据这些请求头完成路由与计量。
列表结果可缓存
tools/list、prompts/list、resources/list、resources/read 的响应现在携带 ttlMs 与 cacheScope，见 SEP-2549。ttlMs 表示建议的缓存时长；cacheScope 则指明该缓存能否跨授权上下文共享，帮助客户端选择合适的缓存策略并减少不必要的重复请求。
授权
过去一年与实现者的交流表明，授权是集成 MCP 时最耗费时间的部分。因此，这次规范继续推进 MCP 的授权与安全机制。
- 授权服务器应按 RFC 9207 返回
iss参数；客户端须在兑换授权码前验证它，见 SEP-2468。这可防止授权服务器混淆攻击。 - 客户端在 DCR 时设置
application_type，授权服务器便不会再拒绝桌面应用和 CLI 的localhost重定向，见 SEP-837。这也解释了某些 CLI OAuth 流程出现redirect_uri错误的原因。CIMD 将成为标准方案；这一调整同时使协议更符合 OAuth 的安全要求。 - 客户端凭据与签发它的 issuer 绑定，不能跨授权服务器复用，见 SEP-2352。
- DCR 已被正式弃用，CIMD 将取而代之。为兼容既有实现，DCR 目前仍可使用，但会在未来规范版本中移除。
Tasks
Tasks 从实验性核心能力迁入 io.modelcontextprotocol/tasks 扩展，提供轮询式 tasks/get 与新的 tasks/update，见 SEP-2663。变更通知也从旧的 HTTP GET 端点迁移到 subscriptions/listen 流；客户端可按通知类型选择订阅。
弃用项
Roots、Sampling 和 Logging 已弃用，见 SEP-2577。它们仍会至少继续可用 12 个月，但新实现不应再采用。旧版 HTTP+SSE transport 同样已正式弃用，并有一年的过渡窗口。
SDK
截至本文发布，四个 Tier 1 SDK 均已支持 2026-07-28：
除 Tier 1 SDK 外，Rust SDK 已以 beta 形式支持该规范。
这些 SDK 提供了使用新规范构建 MCP 客户端和服务器的 API。正如 SDK beta 公告所述，依赖会话标识符的实现会有一定迁移成本；早期测试反馈已被纳入设计，以降低这一过程的难度。
生态系统支持
与任何大型版本一样，MCP 的演进离不开整个生态的贡献。规范正式可用前，许多贡献者和合作伙伴参与了测试与验证。以下为原文中的合作伙伴观点：
这是自远程 MCP 在一年多前首次发布以来最重要的一次版本更新。它吸收过去 18 个月的经验，为可扩展 MCP 服务器和 MCP 的未来打下坚实基础；新增扩展也展现了开源项目持续的创新。
David Soria Parra，MCP 共同发明人、技术人员
这是 MCP 正在成为真正生产级基础设施的最清晰信号。最大的变化带有破坏性，但社区选择完成艰难的工作，而不是掩盖问题。这正是企业生产团队一直等待的成熟过程。
Alex Salazar，CEO、联合创始人
新规范及其无状态协议核心已在 Amazon Bedrock AgentCore 中提供。开发者可以在标准的可扩展基础设施上部署 MCP 服务器，而不必管理会话或持久连接；由 AWS 贡献的 Tasks 扩展则为可靠的长时间运行 Agent 提供支持。
Swami Sivasubramanian，Agentic AI 副总裁
MCP 2026-07-28 让 Agent 基础设施更接近 Web 的工作方式：无状态、可缓存、可路由并可全球扩展。Cloudflare Agents SDK 从发布首日就支持这一规范。
Brendan Irvine-Broque，产品管理高级总监
随着使用量增长，无状态架构可以一同扩展；借助 MCP Apps、Tasks 与企业托管授权，我们可以让设计和代码保持在同一条连通的工作流中。
Josh Clemm，工程副总裁
该版本代表企业 AI 可扩展性的重要跃升。无状态架构降低了大规模部署 Agent 工作流的摩擦，并为下一代 AI 应用提供了可靠、安全、可扩展的基础。
Anna Berenberg，Engineering Fellow
在 honeycomb.io，近 20% 的月度交互式查询已由 Agent 发起。新规范让我们能够在企业规模下支持 elicitation 等更高级的能力。
Austin Parker，AI 战略总监
新版规范解决了 Manufact 在 mcp-use 和 Manufact Cloud 中遇到的实际问题。SDK v2 借助新的客户端/服务器拆分，让包体积缩小约 83%，速度提升 25%；无状态 MCP 也使生产流量能够以更可靠、更安全的方式扩展。
Enrico Toniato，CTO
MCP 是 Microsoft Foundry 的基础，使我们的集成从数十个扩展到数千个。无状态运行、长时间任务和企业托管身份，使新一代 MCP 更容易用于构建安全、可扩展、可上线的 Agent 系统。
Tina Schuchman，Microsoft Foundry 工程副总裁
无状态核心使 MCP 成为一等 HTTP workload，无须绕开会话管理问题。将 MCP Apps 纳入新的扩展框架，是生态系统可扩展性、可访问性和能力上的重要进展。
Sean Roberts，应用 AI 副总裁
MCP 目前约有一年半历史。得益于开发者和合作伙伴的反馈，它正吸收数十年 Web 协议设计的经验，演变为更成熟的协议。
Nick Cooper，MCP 核心维护者
把 MCP 转为无状态协议，使我们的服务更容易扩展，也更容易为客户的 MCP 服务器提供分析能力。
Paul D'Ambra，产品工程师
对于大规模构建 MCP 的团队，这是一个里程碑版本。FastMCP 4.0 将为后台任务、无状态交互、企业授权等能力提供一流支持。
Jeremiah Lowin，CEO
此次更新让 MCP 更适合企业使用，为组织部署 MCP 和 Agent 提供了更简单、更安全的基础。
Tal Peretz，联合创始人兼 CPO
这次修订体现了规范在真实部署经验推动下的成熟。转向无状态模型降低了运维复杂度，也在企业规模上释放了 MCP 的能力。
Craig McLuckie，CEO
对无状态运行的 Supabase MCP 而言，MRTR 让工具可在执行前向用户确认，例如创建项目的成本或可能删除数据的查询。
Inian Parameshwaran，产品负责人
开放的 MCP 2026-07-28 规范中的无状态核心降低了我们需要管理的复杂度，使我们能更快、更大规模地为客户交付更多能力。
Andrew Goodman，AI 副总裁
开始使用
如需基于新规范构建，请参考：
致谢
本次发布离不开庞大的贡献者与行业伙伴社区。MCP 团队感谢来自规范、文档、SDK、工作组和兴趣小组的数十位关键贡献者，也感谢数百个独立的全球社区提供支持与反馈。团队期待继续随着协议的发展共同演进。